In communication networks, overload occurs when a network element has insufficient resources (e.g., CPU processing capacity, memory, network bandwidth, input/output, disk resources, etc.) to successfully process all of the requests that it receives. Some network elements can experience prolonged overload due to high rates of incoming service requests and/or partial network outage leading to failures. Focused overload is a special case of a network overload where the overload is focused on a subset of the network or network element. This subset can range from network destination (e.g., a telephone number or an IP address) to a group of switching and network servers.
In the absence of overload control, such overloads can threaten the stability of a communication network, and can cause a severe reduction in successful service completions. Ultimately, network elements can fail to provide service(s) due to lost requests resulting in the unavailability of services to clients. Often, overload problems can compound themselves, which can cause even more sustained load on a network element. Furthermore, during overload, the overall capacity of a server(s) can go down, since much of their resources are spent rejecting and/or treating loads that they cannot actually process. Under severe overload conditions, the throughput can drop down to a small fraction of the original processing capacity. This is often called congestion collapse. In addition, overload conditions tend to cause service requests to be delayed and/or lost, which can trigger high rates of client abandonment and/or reattempts.
Traditionally, focused overload is controlled in two different ways. One way is by reducing the incoming load by rejecting service requests. For example, only higher priority sessions or transactions may be allowed and all others may be rejected. Unfortunately, this may cause customer frustration, and ultimately churn, leading to loss of revenue.
Another way focused overload is controlled is by routing the incoming sessions or transaction requests to standby network elements which are usually owned and operated by the same organization that owns the network elements whose overload needs to be controlled. However, this may call for drastically higher capital and operations expense because neither the occurrence nor the duration of the overload events can be accurately predicted. Further, certain drawbacks of utilizing infrastructure element-based implementation of overload control of network elements include:                a) Cost;        b) Time required for testing and integration of overload control element with network;        c) Static allocation of resources;        d) Less flexibility in repositioning the resources; and        e) Tighter coupling of computing and communications resources with pre-designed border features and functions, as related to sessions/transactions.        
Service providers in a dynamic and continuously-evolving networking and service development environment need:                a) Protection of investment, i.e., investment in the resources that can be rapidly repurposed for different revenue generating applications and services; and/or        b) Agility and flexibility, i.e., deploying emerging features and functions utilizing the computing and communications resources that already exist in the network.        
Accordingly, there is a need for a system that enables network operators and service providers to allocate their budget for computing, communications, and control infrastructure development based on expected design limits. Consequently, there would be no need to create and install silos of computing and networking gears for controlling focused overload of network elements.